home *** CD-ROM | disk | FTP | other *** search
/ Languguage OS 2 / Languguage OS II Version 10-94 (Knowledge Media)(1994).ISO / gnu / objcissu.lha / encoding-format < prev    next >
Internet Message Format  |  1993-02-27  |  22KB

  1. Return-Path: <krab@iesd.auc.dk>
  2. Date: Sun, 21 Feb 1993 04:49:36 +0100
  3. From: Kresten Krab Thorup <krab@iesd.auc.dk>
  4. To: gnu-objc@gnu.ai.mit.edu
  5. Subject: Random comments on the `encoding' format.
  6.  
  7. This is a request for a discussion on the list on how the encoding
  8. format should be for GNU objc. 
  9.  
  10. Please regard this `proposed' encoding format as a basis for a
  11. discussion. 
  12.  
  13.  
  14. ****  THIS IS A DRAFT DOCUMENT ****
  15.  
  16.  
  17. The aim of this encoding is to give the runtime system access to the
  18. typeinformation needed for manipulating the most basic C types and
  19. some simple compound types.  This could for instance be used to buld
  20. an argument list used in forwarding.
  21.  
  22. The current encoding format especially lacks information on sizes of
  23. structs, which is needed to implement full forwarding some time in the
  24. future... 
  25.  
  26. This encoding changes some encodings according to the current gcc
  27. encoding.  Some information is added to the encoding, and some
  28. encoding formats are simplified.  
  29.  
  30. Whenever changes are done, this is commented at the following
  31. ***CHANGE*** paragraph.
  32.  
  33. The encoding for struct, union and bitfields are changed.  (the text
  34. describes how and why).  Also the encoding for method argument specs.
  35.  
  36.  
  37. The Encoding Specicification
  38. ============================
  39.  
  40. * SIMPLE TYPES *
  41.  
  42. The encoding of simple types is single characters.
  43. Compound types are longer.
  44.  
  45.  
  46.    [Table 1] encoding of simple types.  
  47.  
  48.     type            encoding
  49.    --------------------------------
  50.        char        "c"
  51.     unsigned char    "C"
  52.     short        "s"
  53.     unsigned short    "S"
  54.     long        "l"
  55.     unsigned long    "L"
  56.     int        "i"
  57.     unsigned int    "I"
  58.     float        "f"
  59.     double        "d"
  60.     
  61.  
  62.  
  63. * SPECIAL VALUES *
  64.  
  65. A number of special values are known to the encoding mechanism.  For
  66. instance `id' is known as a special case.  The following table
  67. descibes these cases:
  68.  
  69.    [Table 2] encoding of special types.  
  70.  
  71.     type            encoding
  72.    --------------------------------
  73.        id        "@"
  74.     Class_t     "#"
  75.     SEL        ":"
  76.     char*       "*"
  77.     void        "v"
  78.  
  79. Other pointers to <type> are encoded as
  80.  
  81.    "^<enc type>"
  82.  
  83. Where <enc type> is the encoding of the type being pointed to.  For
  84. example a pointer to an unsigned long will be encoded as:
  85.  
  86.    "^L"
  87.  
  88. unknown types are encoded using the character "?".  For example
  89. pointers to functions or types that are so complex that the encoder
  90. cannot describe them are encoded using this char.
  91.  
  92. Enumeral `enum' types are encoded using the encoding of a signed
  93. integer "i".
  94.  
  95. Bitfields are encoded with the somewhat awkward string
  96.  
  97.   "b<width>:"
  98.  
  99. The encoding does not distinguish signed or unsigned bitfields.  ** is
  100. this ok ** ?
  101.  
  102.  ** NOTE 
  103.   Consider the following alternatives:  "b[<width>]" "[<width>b]" 
  104.   "b\<<width>\>" e.g. "b<4>" (should <> be saved for protocols?)
  105.  
  106.   ***CHANGE***
  107.  
  108.   The current encoding uses the string "b<width>" which is not
  109.   delimited.  This is a problem since for other purposes we need to be
  110.   able to write <enc><number>.  That is no encoding string may end in a
  111.   number.  [This is used for structs and method argument specs]
  112.  
  113.  
  114. * ARRAYS * 
  115.  
  116. Encoding of arrays is done using a sequence at the form:
  117.  
  118.   "[<nelem><enc>]"
  119.  
  120. Where <nelem> is an integer describing the size of the array
  121. represented as a readable string, and <enc> is the encoding of the
  122. type of elements in the array.  For example, the encoding of the type
  123. of a variable declared as `long my_array[25]' would be "[25l]".  The
  124. 25 is there since the array has 25 elements, and the `l' is the
  125. encoding of a long (see table 1 above).  The <enc> field need not be a
  126. simple type.  It could be eny type encoding as described in this
  127. document.
  128.  
  129.  
  130. * STRUCTS *
  131.  
  132. Struct can be encoded in several forms. If the name of the struct is
  133. know, the following form is used:
  134.  
  135.   "{<size><name>}" 
  136.  
  137. Otherwise if struct is intermediate, a '?' is put at the position of
  138. the name yealding the following string.  This is also used if the type
  139. being encoded is really a typedef of a struct.
  140.  
  141.   "{<size>?}"
  142.  
  143. The <size> field is the equivalent of the c builtin sizeof(struct
  144. <name>), encoded as a readable string. (assuming 32 bit architecture)
  145.  
  146. Examples of encoding of a struct are:
  147.  
  148.    struct timeval {
  149.      long tm_sec;
  150.      long tm_usec;
  151.    };
  152.  
  153.    @encoding(struct timeval)  
  154.  
  155.         =>  "{8timeval}"
  156.  
  157.    @encoding(struct { int elem1; char elem2;})  
  158.  
  159.         =>  "{5?}"
  160.  
  161. The reason why the size is placed first in the description string is
  162. that this value is likely to be more interesting at runtime, than the
  163. name of the struct.
  164.  
  165. One could argue, that a more verbose encoding describing the names
  166. types and offsets of the elements would be nice.  This would look like
  167. this:
  168.  
  169.   "{<size><name>=<offset1><enc1><name1>;...<offsetN><encN><nameN>}"
  170.  
  171. In the general case.  Thus out timeval example form above could be
  172. encoded as: 
  173.  
  174.   "{8timeval=0ltm_sec;4lrm_usec}"
  175.  
  176. which could plausably be used for runtime acces to struct members by
  177. name.  
  178.  
  179.   ***CHANGE*** 
  180.  
  181.   The above definition of the encoding differs from the one currently
  182.   used.  The current encoding does not include information on the size
  183.   of the struct.  This information is needed for the implementation of
  184.   full fledged forwarding which includes copying of arguments.  
  185.  
  186.   Also, if the struct encoded were being pointed to the name was not
  187.   inserted in the string.  This property made the encoding context
  188.   sensitive, which is not a desireable property.
  189.  
  190.   The old encoding format had a special long form, which included the
  191.   encoding for each element.  That is, the above `timeval' example
  192.   would look like "{timeval=ll}".  This information is not worth
  193.   anything, since the layout of a struct given its elements is not
  194.   computable in a portable fashion.
  195.  
  196.  
  197. * UNIONS *
  198.  
  199. Union can be encoded in several forms. If the name of the union is
  200. know, the following form is used:
  201.  
  202.   "(<size><name>)" 
  203.  
  204. Otherwise if union is intermediate, a '?' is put at the position of
  205. the name yealding the string.  This syntax is also used if the encoded
  206. type is really a typedef of this union.
  207.  
  208.   "(<size>?)"
  209.  
  210. The <size> field is the equivalent of the c builtin sizeof(union
  211. <name>), encoded as a readable string.
  212.  
  213. Examples of encoding of a union are: (assuming 32 bit architecture)
  214.  
  215.    union timeval {
  216.      long tm_sec;
  217.      long tm_usec;
  218.    };
  219.  
  220.    @encoding(union timeval)  
  221.  
  222.         =>  "(4timeval)"
  223.  
  224.    @encoding(union { int elem1; char elem2;})  
  225.  
  226.         =>  "(4?)"
  227.  
  228. As for structs one could think of a verbose encoding, which could look
  229. like the following:
  230.  
  231.    "(4timeval=ltm_sec;ltm_usec)"
  232.  
  233. We dont need offset information since they all start at offset 0.
  234.  
  235.  
  236.   ***CHANGE*** 
  237.  
  238.   The above definition of the encoding differs from the one currently
  239.   used.  The current encoding does not include information on the size
  240.   of the union.  This information is needed for the implementation of
  241.   full fledged forwarding which includes copying of arguments.  
  242.  
  243.   Also, if the union encoded were being pointed to the name was not
  244.   inserted in the string.  This property made the encoding context
  245.   sensitive, which is not a desireable property.
  246.  
  247.   Besides, the old encoding had a verbose variant, at the form
  248.   "(<name>=<enc1>...<encN>)"  This extra information is not worth
  249.   anything because one cannot use it to access individual elements by
  250.   name.  It could however be used to calculate the size of the union. 
  251.  
  252.  
  253.  
  254. The encoding of method argument specifications
  255. ==============================================
  256.  
  257. Method arguments are encoded and present at runtime.  This could e.g.
  258. be used for implementing a full fledged forwarding mechanism.  The
  259. encoding format I propose is the following:
  260.  
  261.   "<encR>{?<size>=<off1><enc1><name1>;...}"
  262.  
  263. Where <encR> is the encoding of the return type.  Note that if there
  264. is no return type it is `void' and hence also meaning fully encoded as
  265. "v". 
  266.  
  267. The actual arguments are encoded as an untagged struct.  This is used
  268. for building the intermediate structures needed to do forwarding.
  269. Also, this saves the parsing of the encoded format, since we avoid
  270. introducing new syntax.  The <offset> values are NOT stack offsets.
  271. There is no portable way to access parameters from the stack since
  272. they may partially be passed in registers.  The <offset>'s have the
  273. semanthics as if we had really constructed a struct from the
  274. arguments. 
  275.  
  276.   ***CHANGE***
  277.  
  278.   The old scheme encoded the stack offsets for each argument.  This
  279.   encoding does not make sense if the architecture passes arguments in
  280.   the registers.
  281.  
  282.  
  283.  
  284. The full `Bacus Naur' form for the encoding is:
  285.  
  286.    Encoding: 
  287.         SimpleEncoding 
  288.       | SpecialEncoding
  289.       | PointerEncoding
  290.       | CompoundEncoding
  291.       | '?'                 /* unknown (too complex) type */
  292.  
  293.    SimpleEncoding: 
  294.          <one of "cCsSlLiIfd">   /* numeric types */
  295.  
  296.    SpecialEncoding: 
  297.              <one of "@#:*v">        /* objc types + char* + void */
  298.        | 'b' Number ':'          /* bitfields */
  299.  
  300.    PointerEncoding: 
  301.              '^' Encoding            /* pointer to */
  302.  
  303.    CompoundEncoding:
  304.               '[' Number Encoding ']'                   /* array */
  305.        |  '{' Number Name '=' StructEncList '}'     /* struct */
  306.        |  '(' Number Name '=' UnionEncList ')'      /* union */
  307.    
  308.    StructEncList:
  309.               Number Encoding Name 
  310.            |  StructEncList ';' Number Encoding Name 
  311.  
  312.    UnionEncList:
  313.               Encoding Name
  314.            |  UnionEncList ';' Encoding Name 
  315.  
  316.    Number:   
  317.                <one-or-more of "0-9">
  318.  
  319.    Name:   
  320.               '?'
  321.        |   <one of "a-zA-Z_"> <zero-or-more of "0-9a-zA-Z_">
  322.  
  323.  
  324.  
  325. Return-Path: <burchard@localhost.gw.umn.edu>
  326. Date: Sun, 21 Feb 93 15:47:59 -0600
  327. From: Paul Burchard <burchard@localhost.gw.umn.edu>
  328. To: Kresten Krab Thorup <krab@iesd.auc.dk>
  329. Subject: Re: Random comments on the `encoding' format.
  330. Cc: gnu-objc@gnu.ai.mit.edu
  331. Reply-To: burchard@geom.umn.edu
  332.  
  333. Kresten Krab Thorup <krab@iesd.auc.dk> writes:
  334. > * SPECIAL VALUES *
  335. >     type            encoding
  336. >     --------------------------------
  337. >     char*       "*" 
  338.  
  339.  
  340. Just a minor note: "*" is distinguished from "^c" in the same way  
  341. that STR is distinguished form char*; in each case the former  
  342. specifier is intended to refer to NUL-terminated strings only (this  
  343. constraint cannot of course be expressed directly within in the C  
  344. type system).
  345.  
  346. > * STRUCTS *
  347.  
  348. > Struct can be encoded in several forms. If the name of the struct 
  349.  
  350. > is know, the following form is used:
  351.  
  352. >   "{<size><name>}" 
  353.  
  354.  
  355. [...]
  356. >   The old encoding format had a special long form, which
  357. > included the encoding for each element.  That is, the
  358. > above `timeval' example would look like
  359. > "{timeval=ll}".  This information is not worth
  360. > anything, since the layout of a struct given its elements
  361. > is not computable in a portable fashion.  
  362.  
  363.  
  364. I believe the opposite is true: recording only the size would  
  365. guarantee non-portability, whereas the long form can be (and for  
  366. other reasons, must be) made to work.
  367.  
  368. The problem is that the raw sequence of bytes occupied by the  
  369. structure cannot reliably be reassembled into the original structure,  
  370. if the re-assembly is being done on a different type of machine.   
  371. This difficulty arises in both archiving objects into files and in  
  372. decoding the arguments of remote messages.
  373.  
  374. Also, considering the structure as a sequence of bytes prevents  
  375. pointers within the structure from being followed, when that is  
  376. desired.
  377.  
  378. In fact, any sizes, offsets, or other non-portable information must  
  379. be optional, if they are even allowed in the encoding.  This is  
  380. because otherwise these encodings cannot serve as arg-type specifiers  
  381. for Richard's "apply" function.  For "apply" to work properly, it  
  382. must be possible for user code to portably construct specifications  
  383. of argument types.
  384.  
  385. It's the job of the "apply" implementation to do the translation from  
  386. portable type encoding to offsets, byte counts, and byte ordering.   
  387. For this purpose, it seems to me that there is just one deficiency  
  388. with NeXT's format: it only describes structures one level deep.   
  389. Instead, in case the structure contains structure pointers, the  
  390. descriptions should be provided all the way down.  The purpose of  
  391. recording the structure tags is then to avoid infinite loops.
  392.  
  393. --------------------------------------------------------------------
  394. Paul Burchard    <burchard@geom.umn.edu>
  395. ``I'm still learning how to count backwards from infinity...''
  396. --------------------------------------------------------------------
  397.  
  398. Return-Path: <rms@gnu.ai.mit.edu>
  399. Date: Sun, 21 Feb 93 17:34:43 -0500
  400. From: rms@gnu.ai.mit.edu (Richard Stallman)
  401. To: burchard@geom.umn.edu
  402. Cc: krab@iesd.auc.dk, gnu-objc@gnu.ai.mit.edu
  403. In-Reply-To: <9302212147.AA03544@localhost.gw.umn.edu> (message from Paul Burchard on Sun, 21 Feb 93 15:47:59 -0600)
  404. Subject: Random comments on the `encoding' format.
  405.  
  406.     Just a minor note: "*" is distinguished from "^c" in the same way  
  407.     that STR is distinguished form char*; in each case the former  
  408.     specifier is intended to refer to NUL-terminated strings only (this  
  409.     constraint cannot of course be expressed directly within in the C  
  410.     type system).
  411.  
  412. If there's no way to express it in C, how does the compiler know when
  413. to use * and when to use ^c?
  414.  
  415. Return-Path: <krab@iesd.auc.dk>
  416. Date: Mon, 22 Feb 1993 00:03:15 +0100
  417. From: Kresten Krab Thorup <krab@iesd.auc.dk>
  418. To: rms@gnu.ai.mit.edu (Richard Stallman)
  419. Cc: burchard@geom.umn.edu, krab@iesd.auc.dk, gnu-objc@gnu.ai.mit.edu
  420. In-Reply-To: <9302212234.AA01558@mole.gnu.ai.mit.edu>
  421. Subject: Random comments on the `encoding' format.
  422.  
  423. >If there's no way to express it in C, how does the compiler know when
  424. >to use * and when to use ^c?
  425.  
  426. It doesn't, all char* will be encoded as "*" in the current
  427. implementation.  
  428.  
  429. /Kresten
  430.  
  431. Return-Path: <burchard@localhost.gw.umn.edu>
  432. Date: Sun, 21 Feb 93 17:11:21 -0600
  433. From: Paul Burchard <burchard@localhost.gw.umn.edu>
  434. To: rms@gnu.ai.mit.edu
  435. Subject: Re: Random comments on the `encoding' format
  436. Cc: gnu-objc@gnu.ai.mit.edu
  437. Reply-To: burchard@geom.umn.edu
  438.  
  439. >     Just a minor note: "*" is distinguished from "^c" in the same 
  440.  
  441. >     way that STR is distinguished form char*; in each case the 
  442.  
  443. >     former specifier is intended to refer to NUL-terminated strings 
  444.  
  445. >     only (this constraint cannot of course be expressed directly 
  446.  
  447. >     within in the C type system).
  448.  
  449. > If there's no way to express it in C, how does the compiler know 
  450.  
  451. > when to use * and when to use ^c?
  452.  
  453. Good question.  Just as "id" has become a new built-in type of Obj-C,  
  454. rather than a typedef (at least in NeXT's version of Obj-C), "STR"  
  455. should really become a built-in type as well to make this work.
  456.  
  457. Unfortunately, what has happened in real life is that "STR" hasn't  
  458. caught on, and so NeXT treats char* as "*" (e.g. for distributed  
  459. object messages).
  460.  
  461. I guess this is where fans of "constraint-based languages" start  
  462. snickering....
  463.  
  464. --------------------------------------------------------------------
  465. Paul Burchard    <burchard@geom.umn.edu>
  466. ``I'm still learning how to count backwards from infinity...''
  467. --------------------------------------------------------------------
  468.  
  469.  
  470. Return-Path: <krab@iesd.auc.dk>
  471. Date: Mon, 22 Feb 1993 12:13:18 +0100
  472. From: Kresten Krab Thorup <krab@iesd.auc.dk>
  473. To: burchard@geom.umn.edu
  474. In-Reply-To: <9302220010.AA03620@localhost.gw.umn.edu>
  475. Subject: Re: Random comments on the `encoding' format.
  476. Cc: gnu-objc@gnu.ai.mit.edu
  477.  
  478. Paul Burchard quotes me:
  479. >> Ok, I guess it is about time to define what a `portable
  480. >> encoding' mean.  What is your definition? 
  481. >
  482. >By this I mean a format that:
  483. >
  484. >    * can be constructed at run time with portable code (code
  485. >        not containing implementation-dependent constants)
  486. >    
  487. >    * can be used to reconstruct data stored to a file or stream
  488. >        (even if stored from a different machine)
  489. >
  490. >I guess this still isn't a complete definition, though, because there  
  491. >is some conflict in these goals.  Suppose we have compiled identical  
  492. >code on two machines where sizeof(int) is not the same.  On the one  
  493. >hand. we would like to be able to share "identical" data structures  
  494. >between the 2 versions of the same program (which want to believe  
  495. >they are simply dealing with ints).  On the other, there is clearly  
  496. >potential for trouble in transferring data from large size to small.
  497.  
  498. I do not agree in this definition. The encoding is only encoding
  499. of types, not values!  It will have two major purposes:
  500.  
  501.   * Provide information for easy access to data of the given
  502.     type, in a local manner.
  503.  
  504.   * Provide the _basis_ for machine specific procedures, which can
  505.     encode data in a host independent manner.
  506.  
  507. That is the encoding is primarily for use locally, but can be used for
  508. encoding in some binary `XDR' like format.  I think the routines for
  509. this data encoding should be machine specific.  We can possibly
  510. express them in terms of the configuration parameters for gcc.
  511.  
  512. We could possibly define two different `external representations'.  One
  513. binary, xdr-like format, and one ascii encoding where e.g. integers
  514. are written out and must thus be parsed to give sense.  The latter is
  515. inheritly portable, but probably also slower.
  516.  
  517. /Kresten
  518.  
  519.  
  520. Return-Path: <billb@jupiter.fnbc.com>
  521. From: billb@jupiter.fnbc.com (Bill Burcham)
  522. Date: Mon, 22 Feb 93 09:45:53 -0600
  523. To: gnu-objc@gnu.ai.mit.edu
  524. Subject: Re: Random comments on the `encoding' format.
  525. Cc: Kresten Krab Thorup <krab@iesd.auc.dk>
  526.  
  527. Some of my random thoughts about your random comments...
  528.  
  529. Kresten Krab Thorup Writes:
  530. > * STRUCTS *
  531.  
  532. > Struct can be encoded in several forms. If the name of the struct  
  533. is
  534. > know, the following form is used:
  535.  
  536. >   "{<size><name>}" 
  537.  
  538.  
  539. > Otherwise if struct is intermediate, a '?' is put at the position  
  540. of
  541. > the name yealding the following string.  This is also used if the  
  542. type
  543. > being encoded is really a typedef of a struct.
  544.  
  545. >   "{<size>?}"
  546.  
  547. > The <size> field is the equivalent of the c builtin sizeof(struct
  548. > <name>), encoded as a readable string. (assuming 32 bit  
  549. architecture)
  550.  
  551.  
  552. C and objective C use structural equivalence (not type equivalence)  
  553. if I am not mistaken.  So why do we need/want to keep the name of the  
  554. structure.
  555.  
  556. A completely seperate issue I have is with the whole _size_ thing.   
  557. Will storing sizes (a la sizeof()) of things hamper us when we want  
  558. to do distributed objects?
  559. ---
  560. +--------------------------------+----------------------------------+
  561. |          Bill Burcham          | "Make no small plans; they have  |
  562. | First National Bank of Chicago | no magic to stir men's souls"    |
  563. |    billb@fnbc.com  (NeXTmail)  |      Daniel J. Burnham           |
  564. +--------------------------------+----------------------------------+
  565.  
  566. Return-Path: <burchard@geom.umn.edu>
  567. Date: Mon, 22 Feb 93 11:05:44 -0600
  568. From: burchard@geom.umn.edu
  569. To: billb@jupiter.fnbc.com (Bill Burcham),
  570.         Kresten Krab Thorup <krab@iesd.auc.dk>
  571. Subject: Re: Random comments on the `encoding' format.
  572. Cc: gnu-objc@gnu.ai.mit.edu
  573.  
  574. billb@jupiter.fnbc.com (Bill Burcham) writes:
  575. > C and objective C use structural equivalence (not type
  576. > equivalence) if I am not mistaken.  So why do we need/want
  577. > to keep the name of the structure. 
  578.  
  579.  
  580. For encoding circular data structures.
  581.  
  582. Kresten Krab Thorup <krab@iesd.auc.dk> writes:
  583. > [The encoding] will have two major purposes: 
  584.  
  585.  
  586. >   * Provide information for easy access to data of the given
  587. >     type, in a local manner.
  588.  
  589. >   * Provide the _basis_ for machine specific procedures, which can
  590. >     encode data in a host independent manner.
  591.  
  592. I agree totally.
  593.  
  594. > That is the encoding is primarily for use locally, but can
  595. > be used for encoding in some binary `XDR' like format. 
  596.  
  597.  
  598. The one snag in trying to keep things local like this is that for  
  599. distributed objects, a proxy often needs to ask its remote delegate  
  600. what sort of arguments it was supposed to have received from a  
  601. message sent locally to the proxy.
  602.  
  603. This information allows the proxy to bundle up the arguments (using  
  604. local machine config info) and ship them over to the remote object  
  605. properly (where they will be resurrected using the remote machine  
  606. config info).  So the arg type encodings (e.g. as returned by  
  607. -descriptionForMethod:) must be presented "portably" in the sense  
  608. that I described.
  609.  
  610. > I do not agree in [Paul's] definition. The encoding is only
  611. > encoding of types, not values!
  612.  
  613. I don't think we are disagreeing here---after all, the sole purpose  
  614. of types is to define the semantics of values!  Rather, the crux of  
  615. the entire set of problems we are dealing with in this mailing list  
  616. is that some portion of the semantics is not defined within the  
  617. language, and so not portable.  How to handle this is difficulty?   
  618. That's the one legitimate cause for impassioned debate.
  619.  
  620. The only question is, then, upon whom does the responsibility fall to  
  621. translate the portable, language-level semantics into the complete,  
  622. low-level semantics required for various operations?  My preference  
  623. is that the knowledge of how to make such translations be compiled  
  624. into each runtime, and made available via library functions like  
  625. "apply" and "__builtin_classify_typedesc".  I don't think that it  
  626. should be the programmer's responsibility.
  627.  
  628. You are right that in this direct form, the encoding is less  
  629. efficient because of the translation step.  For this reason, allowing  
  630. optional low-level information to be cached in the encoding string  
  631. might be reasonable.  However, for the complete low-level info, which  
  632. will _only_ be used locally and does not need to be transported  
  633. anywhere, it might make more sense to cache the info in an even more  
  634. efficient way---directly in a typed_data_t structure (as previously  
  635. proposed for "apply").  I think the reason for having a string  
  636. encoding is that it's easily transported and easily created in user  
  637. code---so its burden should be to carry the portable info.  Library  
  638. functions can then translate it into low-level info stored in  
  639. structures.
  640.  
  641. I think Richard's proposal to include width information in the string  
  642. encoding is a good idea, though, because it helps make cleaner  
  643. decisions when transporting data.  For example, the low-level  
  644. functions could check for overflow when reading in a 64-bit int into  
  645. a machine with 32-bit ints.
  646.  
  647. --------------------------------------------------------------------
  648. Paul Burchard    <burchard@geom.umn.edu>
  649. ``I'm still learning how to count backwards from infinity...''
  650. --------------------------------------------------------------------
  651.  
  652.